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REMARKS 

I INTRODUCnON 

In response to the Office Acdon dated March 24, 2004, please consider the following 
remark:^. 

IL ALLOWABLE CLAIMS 

In paragraph 14, the Final Office Action indicates that claims 4, 10, and 16 are aflowable. 
The Applicants acknowledge and thank the Examiner for the identification of patentable subject 
matter, but traverse the rejection of the remaining claims for the reasons described below, 

HL STATUS OF CLAIMS 

Claims 1-8 and 10-19 are pending in the application. 

Qaims 1-3, 5-8, 1 1-15, and 17-19 were rejected under 35 U.S.C §l03(a) as being 
unpatentable over Benson, EP 0936530 (Benson) in view of Gabrielle) **USB Forum Produces 
Logo, Awareness Iniriatives," 1997, Computer Retail Week, n 192, pg. 49 (Gabrielle). 

IV. STATUS OF AMENDMENTS 

No amendments to the claims have been made subsequent to the final Office Acdon. 

V. ISSUES PRESENTED 

Whether claims 1-3, 5-8, 11-15, and 17-19 are patentable under 35 U.S.C § 103(a) over 
Benson in view of Gabrielle. 

VI. GROUPING OF CLAIMS 

The rejected rinims do not stand or fall together. Each rW\trt is indcpendendy patentable. 
Separate arguments for the patentability of each claim axe provided below. 
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VII. ARGUMENTS 

A. The Independent Claims Are Patentable Over The Prior Art 

1 . The Benson Reference 

European patent applications EP 0 936 530 (hereinafter the Benson reference) discloses a 
virtual smart card. The virtual smart card emulates a real smart card by providing identical inter&ce 
imd services. The virtual smartcard has no physical manifestation and any smartcard-aware 
^plication can seamlessly interface with either a real smartcard or the virtual smaxtcatd. A virtual 
smartcard server or duplication-protected physical media communicates with the virmal smartcard in 
order to activate or deactivate the virtual smartcard. 

2. The Gabrxcllc Reference 

'TJSB Forum Produces Logo, Awareness Initiative" by Gabrielle C Mitchell, Computer 
Retail Week 1997, n, 192, pg. 49 (hereinafter, the Benson reference) is a news story about the use of 
USB^iompliant devices. 

3. The Subject Invention 

The Applicants' invention is a compact, self-contained, personal key. The personal key 
comprises a USB-compliant interface releaseably coupleable to a host processing device 
operating under command of an operating system. Importantly, the token comprises (1) a 
smartcard processor having a smartcard processor-compliant interface for communicating 
according to a smartcard input and output protocol, and (2) an interface processor implementing 
a translation module for interpreting USB-compliant messages into smartcard processor- 
compliant messages and for interpreting smartcard processor-compliant messages into USB- 
compliant messages. These features provide specific advantages described in the Applicants* 
specification; 

First, smancaxd processors 320 are tehnvdy inexpecslvc and icadUy ;LV9ilabIc. Second, u laig^ number of 
applicanon programs 110 have been developed for the use of smaitcards, including die personal 
computer/smarreard (PC/SQ interface developed by the MICROSOFT CORPORATION. By providing a 
smartcard processor (udiich complies with the smartcard I/O protocols and supports smartcard command 
sets), this software can be used witii a personal key 300 in a USB-compliant form factor. (5pecificaiion» page 
10, lines 1-7) 
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With these features in mind, we now turn to the rejection of claims 1-19. 

4. Independent Claim 1 is Patentable Over the Benson and Gabrielle References 
Claim 1 recites: 

a martcard processor having a smaricard processor-compliant inttrface for comrnunicating according 
to a smariaml input and output protocol; 

an interface processor, communicatively coupled to the USB-compUant interface and to smartcard 
processor-compliant interface the interface processor implementing a translation module for intcTpreting USB- 
co/npliant messages into smartcard processor-compliant messages and for interpreting smartcard processor* 
compHant messages into V SB-compliant messages. 

As described below, even when combined, the Benson and Gabrielle references fail to 
disclose either a srnattcard processor or an interface processor, 

a) Benson and Gabmlk FaiJ to Disclose a Smartcard Processor 

The First Office Action argued that the Benson reference discloses a token having a smart 

card processor as follows: 

As opposed to a physical smaru caird reader, a virtual smartcaid re^a: 5 is virtual haidwarc acting aa 
an ctntdator that passes informatioii co and fxom a Virtual Smart Card 6. Additionally, the Virtual Smart Card 
Reader 5 communi cares with a Virtual Sraan Card Server 8 (VSC Server) via a network 7, e.g., an Intranet, 
Exrranei, or the Imemet (col 6, lines 38-45) 

The VSC Server 8 stores all pzotecred infotmation in its database (encrypted using the respective 
protection key?). When a Virtual Smart Card owner inscm a Virtual Smart Card 6, the VSC server 8 
downloads il;c protected informatioa; and when the owner removes a Virtual Sman Card 6, the Virtual Smart 
Card 6 upload^ the updated protected infomrifltLQa to the VSC Server 8. (col. 6, line 38 through col. 7, line 5) 

The Applicants respcc:tfuUy traversed, because the foregoing passages do not disclose a 
personal token having a smartcard processor, but rather, a Virmal Smart Card (VSC), which is 
essentially a smartcard emulator. Essentially, the Benson reference discloses a virtual smartcard, Le, 
softwarey running on a general purpose processor, that emulates the behavior of a smartcard. The 
Applicants* invention, in contrast, uses a smartcard processor, not a smartcard emulator. 

The Final Office Action responded that since the Applicants have not claimed a ptysical 
smartcard processor, dais argument is moot. 
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The Applicants disagree. 

The Final Office Action's interpretarion of "smartcard processor" is improper. MLP.E.P § 
21 11 states daat *T)nting patent examination, the pending rl^itng, must be *given the broadest 
reasonable interpretation consistent with the spictftcaUan^^ 

The spedficarion is replete with references to the smartcard processor as a hardware device, 
and nowhere is it described as a software modxJe or an emulator of any kind: 

Fii3t, to comply with XJ5B interface protocol icqvuxcmcnts, current USB-compliant personal keys utilize spcckil 
purpose processors, instead of the low cost^ limited capability processors currently avaikble for smartcards. 
This incteflses the cost of the USB-compliant personal key. making widespread acceptance more diffimlr. 
Also, because each TJSB-compatiblc personal key may use a different proceisor (and different mstmcdon sets), 
users may require different device drivcxs for different personal keys. This too represents another barrier to 
widespread acceptance of the personal key. (page 3, lines 8-15) 

From the foregoing, it is apparent that there is a need for a USB-compliant personal key that is usable with 
legacy personal identification devices, such a» processors having smartcard processors and/or those complying 
with the ISO 7816. (page 3, lines 16-22) 

FIG. 3 illustrates the smartcard processor 320, and is discussed in the text reproduced below: 
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FIG. 3 is a block diagram of tlic personal key 300 and host computer 102 as applied to the present 
invention. Unlike the personal key 200 illustrarcd in FIG. 2. the personal key 300 illustrated in FIG. 3 
compnses a smartcard processor 320. The smartcard promsor 320 is a processor which complies with 
weU'knowtt smartcard I/O protocols and smartcard command sets and Junctions, such as those 
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described by the InUmationat Standards Organization (ISO) standard 7816 Part HI (defining 
ekctronk properties and transmission characteristics), which is hereby incorporated by reference 
herein. 

Pliywcally» the smaircaid compliant I/O inteAce 324 includes a scml I/O line, a reset (RST) line, a 
clock (CUC) linc> a progtamimiig voltage (VPP), a power supply vokagc (VCC) and a ground. This I/O 
interface 324 is further desctihed m the publication "Intioduction to Stnnrtcards" by Df , David B. Everett, 
which was published in 1999 by the Smart Card News Ltd,, and is incorporated by reference herein. 

As was the case with the personal key 200 and host compuicr 102 iflustraied in KEG. 1, the present 
invention allows die use of a persona] key 300 communicaiing widi the host computei 102 via a USB- 
compliant interface 130. However^ the substitiUion of the smartcard processor 320 for the ordinary 
processor 212 depicted in FIG, 2 ba% several advantages. First, smartcard processors 320 are relatively 
inexpensive and readily available. Second, a large mmber of application programs HQ have been 
developed for the use ofsmartcards, including the personal computer/smartcard (PC/SC) interface 
developed by the MICROSOFT CORPORATION, By providing a smartcard processor (which complies 
with die smaxtcaid I/O protocols and sopporoj smartcard command seis). tVh'^ software can be used with a 
personal key 300 m a USB-compIiant form £actor,(page 9, line 12 - page 10, line 7, emphafii* added). 

The reset signal is used to start up the program contained in a memory 322 communicatively 
coupled to or resident within the smartcard processor 320, The ISO standard defines three reset modes, 
internal reset, acdvc low reset, and synchronous high active reset Most smancard processors 320 operate 
ufiing the active low reset mode. In this mode, die smartcard processor 320 transfers control to the enriy 
address for die program when the reset signal remms to the hi^ voltage level. The synchronous mode of 
operanon is mote commonly mer with smartcards used for telephonic applicaiions. 

The sequence of operations for activating the smartcard processor 320 is defined in order to 
minimise the possibility of damaging the smartcard processor 320, Of particular importance is 
avoiding corruption of the non-volatile memory 322 of the smartcard Most smartcard processors 320 
operate tising an active tow reset mode in which the smartcard processor 320 transfers control to the 
etary address for the program when the reset signal returns to the high voltage level The sequence 
performed by the smartcard processor includes the steps of setting the RST line low^ applying VCC to 
the proper supply voltage, setting the I/O in the receive mode, setting VPP in the idle mode, applying 
the clock, and taking the RST line high (active low reset), (page 12, lines 6-23, emphasis addec^ 

FIG, 3 and the rekted discussion leads to die inescapable conclusion that the "smartcard 
processor" is indeed a hardware device: Further examples in the Applicants' specification aboxind* 

The Final Office Acnon's interpretation of the "smartcard processor" as a non-physical 
device or a smartcatd emulator is completely inconsistent the specification, and is therefore 
impettmssible under M,P.E.P. § 2111. 



b) Benson emd Gabmtk Fail to Disclose an Interface Processor 
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Claim 1 recites that the token comprises an ini^rface processor and a ttanslarion module, 
which interprets USB-compliant messages into smartcard processor-compliant messages and 
interprets smartcard-compliant messages into USB-compliant messages. The First Office Action 
argaed that Benson disclosed diese feamres as follows: 

The VSC Server then permits the oumer to use the Vinual Smart Card. When the Virtual Smart Card 
ownci pcrfoixns a remove opeiadon, the Virtual Smart Card disables itself secuicly sends a remove request to 
the VSC Server, and then shuts itself do\xris. When the VSC Server receives a remove request, the VSC Server 
resets the Virtual Smart Card'e state m the database to be idle. 

An alternative to the communication between the Virmal Smart Card and the Virtual Smart Card 
Server Is presented in claim 10, The Virtual Smart Card Reader communicates \with a donglc (or some other 
duplication-protected physical media), A di^Ucation protected physical media has the property that it is 
exceedingly difficult for an unaudiorized attacker to construa a copy of the media. The Virtual Smart Card is a 
copy protected program that executes only if permitted by the Dongjc. If the end-usei attaches the Donglc to 
the machine, then the Virtual Smart Card eacecuies; otherwise, the Virtual Smart Card slops. (coL 4, lines 4-23). 

and 

Insert 104: The end-user attaches the don^e 1101 and boots the Virtual Smart Card 6 program. Hie Virtual 
Smart Card 6 program does not operate unless the Virtual Smart Card 6 program can validate that the Dongle 
1101 is present. The state of the Virtual Sman Caid 6 is in-usc 102 after the Virtual Smart Card 6 detects the 
Dongle UOl. This state is not explicitly recorded as in the ca*e with the VSC Server 8. (coL 24, Hues 8-16). 

The Applicancs disagreed, stating: 

'The foregoing describes the interaction between a the Vurtual Smart Card and the Vimial 
Server (or, in coL 24, a Dongle). It does not describe a token with an interface processor^ 
and docs not describe an entity that is coupled between a smartcard processor and a USB- 
compliant inter&ce, and does not describe any entity that interprets USB-compliant 
messages into smartcard-compliant messages or smartcard-compliant messages to USB- 
compliant messages- The Gabrielle reference is likewise deficient" 

To which the Final Office Acdon replies: 

''Benson discloses a smartcard processor in a personal key (virtual smartcard) is enabled by 
use of an interface processor^ because the interface processor includes a smartcard reader 
emulator, that functions to emulate ±ose of a smartcard reader^ thus projecting an image of 
a smartcard reader to the smartcard processor (sec col. 6, lines 30-45). 

The referenced portion of the Benson reference is reproduced below; 



-12- 



G&C30a74.27-US-Il 



PAGE 1 »23 ' RCVD AT m04 6:49:29 PM [Eastern Daylight 



05-24-2004 03:01PM FROM-Cates & Cooper LLP 



+13106418798 T-546 P. 016/023 F-661 



;fo [0O23] Figure 1 iHustrHtes the Virtual Smart Card 
architecture. Smart cand awara user application 1 com- 
municates with the 'smart card" via th DLLs of a smart 
card service pravid ar 2. The smart card service provaer 
2 relies i^xm the services of the Smart Card Reeource 

35 htoiago* 3 which communicate with a Smart Card 
Reader He^er Driv^ 4 and a Virtual Smart Card 
Reader Drivers, 

[002f] As opposed to a physical smart card reader, a 
Virtual Snoart Card Reader 5 is virtual hardware acting 
4a as a ermjiator that passes informaHon to and from a Vir- 
tual Smart Card 6. AddttionaSly. the VIrtL»l Smart Card 
Reader 5 conrvnuntcates with a Virtual Snnart Card 
Server 8 (VSC Server) via a network 7, an Intranet 
Extranet or the internet 

43 



PlaiiUy, the foregoing does not disclose an "JnUrface processor, cotnmunicattvefy coMpkd to the USB' 
cOTPTpliant interface and to wtarUard processoiHompliant inietface the interface processor implementing a trcmslatio^n 
module for interpreting USB-compUant messages into smartcctrdprocessor-comphant messages and for interpreting 
smartcard processor-compliant messages into USB-co^liant messages" , as recited in claim 1 , 

Referring to the same portion o£ the Benson reference^ the Final Office Action also states: 

**Bcn$on also discloses that the virrual smartcard reader passes information to and from the 
virtual smartcard (see col. 6, lines 30-45), Therefore, the Examiner asserts that commands 
are sent and executed using a software emulation as done by Benson." 

Of course, simply "passing information" does not teach the interface processor features 
recited in claim 1 . The Applicants therefore respectfully traverse. 



5, Independent Claim 8 is Patentable over the Benson and Gabrielle References 
Claim 8 recites: 



A host processing device, comprising: 
a processor, 

a memory, communicatively coupled to the processor, the memory storingprocessor ttperation 
commands implementing an operating system; and 
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a virtual smartcard reader module stored in the memory and in communication with the 
QperaUng system, for emulating at least one smartcard reader to the operating system, the virtual 
smartcard reader module comprising a comrnunication module for packa^ng smartcatd-compliant 
commands for transmission to a personal token communicative^ coupled to the host processor ma a 
VSB-covipUant interface and for ur^acking smartcard-compSant responses received from the 
personal tokem 

The First Office Action argued that these features were disclosed in the Benson reference as 
foflows; 

As opposed to a physical smart caid reader, a virtual smartcard reader 5 is vinual hardware acrtag as 
an emulator that passes infoianacioxi to and &oni a Vktual Simrc Card 6. Additionally, the Vtmial Smart Card 
Reader 5 couimwucates with a Virtual Smart Card Server 8 (VSC Scivci) via a network 7, e.g., an Intranet, 
Extranet, or the Internet. (coL 6, lines 38-45} 

The VSC Server 8 stores '^11 protected information in its database (encrypted using the respective 
protection keys). When a Virtual Smart Card owner inserts a Virtual Smart Qaxd 6, dae VSC server 8 
downloads the protected information; and when the owner removes a Virtual Smart Card 6, die Vimial Sman 
Card 6 uploads the updated protcrtcd information to the VSC Server 8- (coL 6, Kne 38 through col. 7, line 5) 

The Applicants traversed this rejection, because Benson does not disclose a virtual smartcard 
reader having a communication module packaging smartcard compliant commands to a personal 
token. As disclosed in Benson as follows, the "dongle" is used to authorize the execution of the 
Virtual Smart Card program; 

Figure 15 illustrates an alternative implementaiion of die Virtual Smart Card ^. This implementadon 
docs not require a VSC Server 8. 

Instead of commtmicaiing with the Virtual Smart Card Server 8 die Virtual Smart Card Reader 5 
communicates with duplicadon-protecced physical media, e.g., a Dong^ 1101. A duplication protected physical 
media 1101 has die property that it is exceed^gly difficult for an unauthorized attacker to constmct a copy of 
the media 1101. The Virtual Smart Card 6 is a copy protected program that executes only if permitted by the 
Dongle llOl. If die end-user attaches die Dongle 1101 to the machine, then die Virtual Smart Card 6 executes; 
otherwise, the Virtual Smart Card 6 stops.(coL 23, lines 31-44) 

Further, smartcard commands are not sent to either die Virtual Smart Card Server or the 
dongle. Instead, these entidcs act only as data repositories where protected data is stored and 
retrieved. There is no teaching to translate or package smartcard commands or responses. 

Apparently acknowledging that there is no express teaching of a communication module in 
Bcr^on, the Final Office Acdon argues that one is inhcrendy disclosed; 
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^Tirst, a communication modixle is inherent in Benson, because information is passed to 
virtual smart card reader £com the virmal smart card (see coL 6, lines 38-45), The Applicant 
is urged to look further down column six, Benson discloses the virtual stnart card stores 
protected information, such as digital signature. When the virtual smart card is inserted, the 
virtual smart card server downloads the protected information, thus there is a 
communication module in Benson (see col. 6, lines 48-58; coL 7, lines 1-5, coL 9, lines 38- 
41)" 



[0025] A Virtual Smart Card 6 ^res protected infor- 
mation that it Quardfi in terms cf conTdeniialfty and 

so integrit/. The most Important ^ampio of pmtdoted infor- 
mation is a private key used for digital signatures, 
decryption, Ke/ management, and possibly other pur- 
poses. O&ier examples of protected information include 
counters used tn software remal appHcations, and conf i- 

£5 dential irribrmetion used healthcare pruviders. 

100261 The VSC Server 8 Btc3r«B all protected intorma- 
tron in 'ns database (encrypted using ttie respective pro- 
tection keys). When a Virtual Smart Card owner Inserts 



7 EP0d36 

a Virtual Smart Card 6. the VSC Server a downloads 
the protected information; ard when the owner r^rmes 
a Virtual Smart Card 6. the Virtual Smart Canj € 
Uploads the ifxteted protected Information to the VSC 
Server 8, s 



Key arxl encrypts the session loa/ using the VSC a? 
Server's public ke/. The VSC Server 8 discovers the 
session Key by applying Hs private Key. The protected 
channel consists of tnfonmation communicated t>etwQen 
the two parties that is encrypted udng the. session key. 
Note that a good implementation of a protected commu- ^ 
nication channel, ag,. SSI, pcovfdes protection against 
cryptoanalysls. e.g.. playback. 



Of course^ the issue isn't simply whether a "commmiication module" is disclosed in Benson 
or not . . . the issue is whether Benson discloses "a communication moduk forpacka^ng smaricctrd-compliant 
commands for transmission to a p^sonal token communicatively coupled to the host processor via a VSh-compliant 
interface and for unpacking smartcard-compBant responses received from the personal toktn'* . as recited in claim 1 . 
A review of the cited portions of the Benson reference reveal that it does not. Accordingly^ the 
rejection of claim 8 is traversed. 
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6, Independent Qaim 14 is Patentable over the Benson and Gabrielle References 
The First Office Action rejected claim 14 on the same basis as claims 1 and claim 3. The 

Applicants traversed this rejection for the reasons described above with respect to claim 1 and 
described below with respect to claim 3 (regarding whether Benson inherendy discloses a 
eommunuation modukforpacka^g messagBiforlransmismn to the pmonal token via the USB compliant interface 
acimMng to a first protocol and for unpacka^ng mssag^s received from the personal token via the USB-compUant 
interface according to the first protocol and an interface processor translation module unpackages messages firm the 
host processing device according to the first protocol and packages messa^S destined for the host processing device 
according to the first protocol^. 

The Final Office Action offered no additional rationale for this rejection. Accordingly, the 
Applicants again traverse. 

7. Independent Claim 19 is Patentable over die Benson and Gabrielle References 
Claim 19 recites: 

A mrtual smartcard reader emulator system, compiising: 

a first smartcard reader emulator^ implemented in a host computer for emulating smartcard reader 
operations to the host computer; and 

a second smartcard reader emulatarp implemented in a personal key,fifr emulating smartcard reader 
operations to a smartcard-interface compliant personal key processor. 

The First Office Action argued that the foregoing features were disclosed in Benson as 
follows: 

The Virtual Smart Caid Render communicates wirh a Dongle (or some other dwpKcattOn-pixnected physical 
media). A duplicanon-protected physical media has the propecty ihar it is exceedingly difficult for an 
unauthorized attacker to construct a copy of the media. The Virtual Smart Card is a copy protected program 
that executes only if pcmutted by ihe Dongle. If the end-user attaches the Donglc to the machine, then the 
Virtual Smart Card executes; otherwise, the Virtual Smart Card stops. (coL 4. tines 14-23) 

and 

Insert 104; The end-user attaches the Donglc 1101 and boots the Virtual Smart Card 6 program. The Virtual 
Smart Card 6 program does not opccatc unless the Virtual Smart Card 6 program can validate that the Dong^ 
1 101 is present. The state of the Virtual Smart Card 6 ia m-u$e 102 lifter the Viitual Smart Caid 6 detects the 
Dongle not. This state is not explicitly recorded as in the case with the VSC Server 8. (coL 24, lines 8-1 6) 
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Of course, nothing in the foregoing text suggests a smaxtcard reader einuktor in a peisonal 
key for emulating smartcard reader operations to a smaxtcard-compliant personal key processor. 

The Final Office Acdon provided no additional rationale and did not cite any further 
portions of either of the cited refctences. Accordingly^ the Applicants traverse the rejecrioa of claim 
19. 

B. The Dependent Claims Are Patentable Over The Prior Art 

1. Dependent Claims 2-7, 10-13, and 15-18 arc Patentable Over the Benson and 
Gabrielle References 

Claims 2-7, 10-13, and 15-18 each recite tlie feature of the claims they depend upon axid are 
patentable on the same basis. In addition, claims 2-7, 10-13> and 15-18 recite additional features 
rendering them even more remote firam the prior art Exemplary daims are discussed below: 

With Respect to C lj^ttn 9-. Claim 2 recites; 

,„whmin ihc interface processor emulates a sntartcca-d reader to the smartcard promsor. 

According to the Office Action, Benson discloses that the interfiace processor emulates a 
smartcard reader to the smartcard processor as follows: 

The invention presents a bxidge technology called Virmal Sman Caid which emulates a real smart card by 
providing an idemical interface and collection of seiviccf;- How&o&t^ the Virtnal S7n(trt CiStd bos no 
physical manifestation. Any smart caid-awaie application can seamlessly intwr-opetate widi either a real 
sman card or a Virtual Smart Card- (col 3, lines 22-26, emphasis added) 

and 

The Virtual Smart Card Reader communicaies with a Dongle (or some Other duplication-protected physical 
media). A dnplicaaon-proiected physical media has the property that it is exceedingly dif&cuh for an 
unauthomed attacker to construct a copy of the media. The Viminl Smart Card is a copy protected program 
that executes only if pcunittcd by the Donglc. If the end-user attaches the Dongle to the machine, then the 
Virrufll Smart Card executes; otherwise^ the Virtual Smart Card stops, (col 4, lines 14-23) 

and 

As oppOi^d to a physical smart card reader, a Virtual Smart Card Reader 5 is a virtual hardware acting as an 
emulator that passes information to and from a Virtual Smart Card 6- Additionally, ±e Virtual Smart Card 
Reader 5 commuxiicates ^th a Virnial Smart Card Server 8 (VSC Server) via a network 7, e.g. an Intranet, 
Extranet, Or the Incemec. (coL 6, lines 38-44) 
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In rc5pott5e> the Applicants pointed out dtat VSC Reader disclosed above merely forwards 
emulated smart card messages unchanged to tlie VSC Server it does not "inteipret USB-compliant 
messages into smartcard processor-compliant messages and for interpreting smartcaxd processor- 
compliant messages into USB-compliant messages", as claim 2 recites. 

The Final Office Action merely reiterated this rejection. Accordingly, die Applicants 
respectfully traverse. 

With Hespecr to Claim 3 : Claim 3 recites that: 

the host processing device cmprisds a virtual smartcard reader ,„ including a comrnumcalion module 
for packaging messages for transmission to thf personal token tm the USB compliant interface according to a 
first protocol and for unpacka^ng messages received from the personal token via the U SB-compliant interface 
according to the first protocol; and 

the interface processor translation module unpackages messages from the host processing device 
according to the first protocol and packages messages destined for the host processing device according to the 
first protocol 

According to the First Office Action, the Benson reference discloses a virmal smartcard 
reader. The Office Action concedes diat the Benson reference does not disclose a "communication 
module for packaging messages for transmission to the personal token via the compliant incerfece 
according to a first protocol" but asserts that this communication module is inherendy disclosed. 

The Applicants respectfully disagreed, pointing out that Benson's Virtual Smart Card Reader 
interfaces directly with the Virtual Smart Card. Since both the reader and the smart card itself 
emulate smartcard processes and messages, there is no reason whatsoever for any sore of cranslation 
or packaging. 

Inherency "may not be established by probabilities or possibilities. The mere face that a 
certain thing may result firom a given set of circumstances is not sufficient " Continental Cem Co* 
Monsanto Co,^ 948 F.2d 1264, l269(Fed. Cir. 1991). Instead, to establish inherency, the exmnsic 
evidence "must make clear that the missing descriptive matter is necessarily present in the thing 
described in the reference, and that it would be so recognized by persons of ordinary skill." 
Continental Can Co., 948 R2d at 1268. 

The Final Office Action responded: 
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'The Examiner asserts that Benson inherently discloses this> because Benson discloses a 
virtual smart card reader that is a virtual hardware acdng as a emulator that passes 
information to and from a virtual smart card (see coL 9, lines 38-41) and for unpacking 
messages received from the personal token via the compliant interface according to die first 
protocol, and the interface processor translation module unpackagcs tnessages from the host 
processing device according to the first protocol." 

The cited portion of the Benson reference is reproduced below; 



Insert 104: The end-user attaches the Dongle 11 01 
and bcots Ihe Virtual Smart Card 6 progranv Tha 

10 \^rtuaj Smart Card 6 program does not operate 
unless the Virtual Smart Card 6 program can vali- 
date that the Dongle 1 101 is preserrt The state of 
me VirtueU Smart Card 6 '» in-use 102 after the Vir- 
tual Smart Card 6 detects the Dongle 1101. This 

15 State Is not eoqalicitty recorded as in the case with 
ihaVSC Sen/erS- 

The Applicants fail to understand how the foregoing discloses the communication module 
and interfece translation modules of claim 3. Accordingly, the rejection is traversed- 



Regarding claims 6. 12, and 17 : Claim 6 recites that the virtual smartcard reader (running in 

the host processing device) comprises a reporting module for receiving and reporting the insertion 

of the personal token in a USB-compliant port and the removal of the personal token as a removal 

of a smartcard from a smartcard reader. According to the First Office Action, Benson discloses 

these features as follows: 

Insert 104: Tlic end-user attaches the Dongle 1101 and boots the Virtual Smart Cai:d 6 program. The Virtual 
Smart Card 6 program does not operate unless the Virtual Smart Card 6 piogtani can validate that the Dongle 
1101 is present. The state of die Vimial Sman Card 6 is in-usc 102 after the Virtual Smart Card 6 detects the 
Dongle tlOl- This state is not explicitly recorded as in the case vnxh the VSC Server 8. (coL 24, lines 8-16) 

At any time after successfully perfoiming an insert opcradon^ a Vimial Smart Card 6 may perform the remove 
opera-tioii (using the proteacd channel established during die insert operation). Firsts the Virtual Sman Card 6 
disables itself by refusing all requests for servicefi. Next, die Virmal Smart Card 6 sends a remove request to 
the VSC Server * which uploads the protected informadon (encrypted using the protection key). Upon receipt 
of a remove request, die VSC Server 8 resets its corresponding database entry to idle and returns a succcua 
acknovdedgement Next, the Virtual Sman Card 6 unbdcs the local machine lock, zeros out the protected 
informadon, and shuts itself down. (col. 13, lines 41 -^SS) 

Instead of communicadng vwth the Virtual Smart Card Server 8. the Virtual Smart Card Reader 5 
communicates with duplicadon-protectcd physical media^ e.g., a Dongle 1101. (col. 23, lines 34-37) 
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Rfimovc 105: The Dong^e 11 01 &ils to auihome the Virtual Smart Card 6. For example, the cnd-uscr cither 
removes the dongic 1101, or the Virtual Smart Card 6 shuts down. The state is idle 101 after the Dongle 1101 
is removed. (coL 24, lines 18-22). 

The Applicants traversed this tejection, as nothing in the foregoing passage appears to 
disclose a virmal stnartcaid reader having a reporting module repotting the insertion of the personal 
token in USB in a USB-compHant port and the removal of the personal token as a removal of a 
smartcard from a smartcard reader. At best, the foregoing independently describes a virmal 
smartcard performing remove operations and sending remove requests, and diat the Virtual Smart 
Card shuts down if the user removes the dongle. 

The Final 0£6ce Action merely reiterated this rejection. The Applicants therefore traverse. 

VIII. CONCLUSION 

In view of the above^ it is submitted that this application is now in good order for allowance 
and such allowance is respectfully solicited Should the Examiner believe minor matters still rcinain 
that can be resolved in a telephone interview, the Examiner is urged to call Applicants' undersigned 
attorney. 



Date: May 24, 2004 
VGC/mrj 



Respectfully submitted, 

GATES & COOPER LLP 
Attorneys for Applicant(s) 

Howard Hughes Center 
6701 Center EJrive West, Suite 1050 
Los Angeles, California 90045 
(310) 641-8797 




Name: Victor < 
Reg. No.: 



Cooper 
39»641 
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